Zane Scott, Vitech Vice President of Professional Services
The ultimate test of any tool is whether or not it helps the user in the way intended at its acquisition. In other words, “Does it do what we need it to do for us?” This is certainly true for systems engineering tools. To judge their value, we must look first and foremost to their performance against our needs.
If this sounds familiar – it should. Like any system solution, our systems engineering tools must meet their requirements. Unfortunately, we rarely conduct this inquiry in such a straightforward way.
So we must begin by eliciting our requirements. This is obvious but not necessarily easy to do. Just like our clients, systems engineers are apt to focus on the “flavor of the month” when it comes to requirements. Rather than return to fundamental purposes, we become ensnared in the latest hype. We elevate one aspect of the tool above others, often sacrificing fundamental capability in the process. We would not sit by silently and let our clients skew their requirements definition process this way, and yet we are content to fall into this trap ourselves.
With that framework, let’s put some meat on those bones. How, exactly, are we making these errors, and how do we return to first principles to equip ourselves with the right tool support?
Capability Elicitation – The Need for Systems Engineering Tools
What is the purpose for systems engineering tools? We should be clear that we are talking about tools for modeling the system solution. We are not addressing special purpose tools such as physics-based modeling tools designed to assess the performance of system components or subsystems. Those valuable tools have their own distinct purposes leading to a wholly different set of requirements, validation, and verification analysis.
In this discussion, we are considering the systems engineering tool used to model the proposed solution. This model is focused on the logical structure of the solution and its implementation in the physical architecture. It has its roots in the purposes of systems engineering itself.
Systems engineering arose in answer to the challenge of designing solutions whose complexity was increasing in direct proportion to the complexity of the problems being addressed. For example, the ballistic missile systems designed in the aerospace and defense seed bed where systems engineering took strong root presented significantly more complex design challenges. As solution architectures required electrical/mechanical/chemical/computer subsystems to perform intricate functions in concert with each other, it became apparent that individual engineering disciplines could not solve chunks of the problems independently. Cross-discipline integration and collaboration was critical.
No sooner had this challenge ramped up than it became clear that the integration and collaboration would require more. The individual brain space of the designers simply could not hold everything necessary for the teams to answer complex questions with the high fidelity demanded by their criticality. It was into this space that tools stepped, promising to become the super-brain that saw all, remembered all, and made all visible to the collaborating human designers.
The basic requirement for a systems engineering tool was that it could encompass all aspects of the design in relationship to each other as they would be in the implemented system. In that way, the tool would allow the designers to think “out loud” about the results that would be produced by various combinations and constructs. The designers could engage in trade studies, configure, and reconfigure the various system elements until the desired results were achieved. All of this became possible only to the extent that the tool was capable of holding a high fidelity model of the design where the design team could see, understand, and modify it.
It wasn’t long until the new systems engineering discipline realized a fundamental schema where requirements were the basis of system behaviors which were allocated to components that performed the behaviors, thereby fulfilling the requirements on which they were based. Once again, the world of complex problems and solutions necessitated a tool that could organize and track the elements in this way. Not only could the users of such a tool explore the design possibilities in search of an optimal solution, but they could also trace and verify the role and structure of the system elements.
From Need to Requirements to Suitability for Purpose
The basic requirements for a robust and useful systems engineering tool are that it be capable of ingesting, storing, and representing the fundamental nature and relationships of the system elements in a construct that is useful to the designers. It must support those designers in creating and communicating a model of the solution that allows them to think about and realize the best possible solution to their problem. There should be no need for the designer to worry about consistency and completeness, because this is managed using the computing power of the tool instead of the memory of the designer. To the extent that a tool does this, it is “good.” To the extent that it does not, it fails the test of a good tool. This failure show it is not fit for the true purpose at hand – supporting the engineering of complex systems.
It should be noted that the rigor with which a tool is held to this standard is directly proportional to the complexity of the model to be constructed. For example, tools that do not maintain a high fidelity model of the solution can work if the engineers using them are willing and able to maintain the missing detail in their heads. But the more complex the solution becomes, the less likely it is that the engineers can meet the demand for completeness and consistency without the aid of a high-fidelity model.
There are a number of ways that a tool can fail the test of a good tool. Take, for example, a tool that allows the designer to independently create pictures of a system design but has no underlying model of the elements held in relationship to each other. Such a tool is useful in facilitating the production of system views but does not meet the test of a true systems engineering tool. Without the underlying model, the tool shifts the burden back to the collective minds of the engineering team.
Just as the fundamental tool of the draftsman – her pencil – can be enhanced with templates that allow her to draw certain shapes more quickly, a tool that provides the ability to construct diagrammatic patterns from previous drawings can ease the burden of constructing subsequent drawings. This is useful, but in both cases it fails to address the central concern of a systems engineering tool – that of managing the complexity of the system solution in a way that removes the burden of maintaining nuance, consistency, and completeness using the mind space of the human engineers. Even in the case of a powerful drawing tool offering numerous templates addressing multiple standard representations, the drawing tool requires that the draftsman maintain a mental model from which to produce the drawings – and, more importantly, manually maintain consistency across all artifacts through time as the design evolves.
A true systems engineering tool, on the other hand, maintains an underlying data model that can be queried to produce whatever view of the data is desired – tabular, graphical, textual, or blended. The query simply specifies the subset of information to be represented and the rules for displaying that data. Consistency is built in as any change in the data model is reflected immediately into any view that is desired. This is the power of a true systems engineering tool.
Another breakdown in the design of tools is the effort to approximate a robust systems engineering tool by weaving together a set of disjoint and limited tools. There might be a requirements tool, an architecture tool, and perhaps others. We are encouraged to believe that the several “models” produced by such limited tools can be aggregated into a cohesive systems model. The fallacy here is that the relationships are broken by definition at the boundaries between these tools. It is as if we were told that a miniature steel structure plus a plumbing fixtures parts list plus a furniture catalog was an architectural model of a building. This is a far cry from a single model contained in a single repository under the control of a single tool.
It is relatively easy to put together a number of established domain-specific tools and claim that by covering all the domains, we are constructing a system model. It is tempting to believe that because we can produce views that conform to one standard or another, we are producing a model of our system design. It is much harder to actually achieve the real integration of the domains into a high-fidelity model of a system solution. But anything short of that fails to meet the real requirements because it does not fully serve us. The complexity of our real-world problems demands that we insist on nothing less.
